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(57) ABSTRACT 

The invention relates to a process for programming; or 
reprogramming a reprogrammable onboard memory (5), 
characterised in that it consists of programming or repro- 
gramming the onboard memory of several modules (MO, Ml 
. . . ) in parallel through a multiple access bus (6) to which 
the said modules are connected. In the case of blank flash 
memories, the invention also defines a process used: to 
download code through the multiple access bus and; to 
execute it, eliminating all external constraints (frequency, 
binary throughput). 

The process according to the invention is more particularly 
intended to be applied to onboard flash type memories. ' 
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METHOD FOR PROGRAMMING/PARALLEL 
PROGRAMMING OF ONBOARD FLASH MEMORY 
BY MULTIPLE ACCES BUS 

[0001] The present invention relates to a process for 
programming and reprogramming any reprogrammable 
onboard memory in parallel through a multiple access bus 
such as a bus operating using the CAN (Controller Area 
Network) protocol, and particularly to program and repro- 
gram onboard flash type memories in parallel 

[0002] The following description is made with reference 
to a flash type memory, although the concept of the inven- 
tion can be generalized to any reprogrammable memory. 

[0003] Note also that the entire description given below is 
made particularly with reference to the use of a CAN bus. 
However, the concept of the invention also includes parallel 
programming/reprogramming of flash memories onboard 
modules through any other bus with multiple accesses not 
dedicated to this purpose and that could be used as a 
substitute for the CAN. 

[0004] Flash memories are EEPROM memories, where 
EEPROM is an abbreviation for Electrically. Erasable Pro- 
grammable Read-Only Memory, with a very short write 
time, a low erase voltage and with high capacity, and are 
frequently used in microcontroller circuits, particularly cir- 
cuits dedicated to communication management for different 
diagnostic tools for an automobile vehicle such as engine 
control, ABS, electronic suspension management, etc, 

[0005] The problem that then arises is to program (or 
reprogram) the onboard memory of these dedicated circuits 
in a minimum amount of time therefore at low cost. 

[0006] FIG. 1 shows a conventional functional diagram of 
a module of the type mentioned above with an on-board 
flash memory. The core of the circuit is composed of a 
microprocessor 1. The microprocessor 1 communicates with 
a system unit in a central computer through an as3mchronous 
serial link 2 of the UART type, where UART is an abbre- 
viation for Universal Asynchronous Receiver-Transmitter. 
An asynchronous transmission interface 3 is then installed 
between the microprocessor 1 and the transmission line 2 to 
enable transmission of data in asynchronous mode. A CAN 
bus can also be provided to communicate with the micro- 
processor through a CAN interface 7. The circuit also 
comprises a chronometer 4 connected to an external oscil- 
lator 8 to determine the frequency at which the system runs, 
and an erasable reprogrammable flash type memory 5. The 
flash memory is usually shared between a test area 5a and a 
user area 5b. 

[0007] In a context in which the flash memories to be 
programmed are blank, it is important to be able to start the 
activity of the microprocessor regardless of the frequency 
conditions under which the system is running and regardless 
of the transmission speed. 

[0008] In prior art, the start methodology used to activate 
the memory is based on the principle of a separation of the 
flash memory into two parts: the flash test part 5a and the 
user flash part 5b. Thus, the flash test is programmed in the 
factory with a minimum program which then loads code 
through the UART serial link. 

[0009] However, nowadays the UART serial link reduces 
the transmission speed which is limited to 9600 bits/s. 
Therefore this physical interface is not suitable for fast data 

transfers. 



[0010] A faster physical Unk is necessary to enable greater 
productivity gains on production lines. 

[0011] Thus, UART type serial links are increasingly 
being replaced by another communication medium which is 
the CAN bus, reference 6 in FIG. 1 and which communi- 
cates with the microprocessor in this circuit through the 
CAN interface module 7. 

[0012] A bus operating according to the CAN protocol can 
achieve much greater throughputs than are possible with a 
conventional asynchronous serial link since the different 
throughputs possible with a CAN bus vary from 125 kilo- 
bits/second to 1 Megabit/second, and there is an intermedi- 
ate rale of 500 kilobits/second, 

[0013] The problem that then arises is to be able to 
program blank flash memories using this communication 
medium and therefore being able to download program code 
directly through the CAN bus and being able to execute it 
regardless of the system frequency conditions and regardless 
of the binary throughput on the link. 

[0014] Solutions have already been proposed in prior art, 
particularly the ATMEL company has developed a micro- 
controller specifically dedicated to applications using a CAN 
network. However, the solution developed by ATMEL is not 
completely satisfactory since it requires additional hardware 
resources, particularly in the CAN module, for error man- 
agement. 

[0015] On the contrary, the invention is intended to avoid 
this disadvantage by implementing additional hardwiare . 
resources. 

[0016] It is important to note straight away that the inven- 
tion is intended to be applicable to a context in which flash 
memories in all modules to be programmed are blank, in the 
same way as a context in which the flash memories are not 
blank, in other words a context in which an identical 
program is already installed in all modules, and this is the 
case particularly when a first programming of a test software 
has been installed in the flash memory and the flash memory 
then needs to be reprogrammed. 

[0017] However, in a flash memory reprogramming con- 
text, in other words in the context in which an identical 
program of a test software had already been installed in the 
flash memory in all the modules, it is necessary to include 
an erase step before the flash memories can be repro- 
grammed as required by the user. 

[0018] The erase step prior to reprogramming takes a lot 
of time, since it can take about 10 seconds per circuit. This 
memory erase operation is essential before reprogramming 
later, and is a severe handicap in a production environment 
that must produce several hundred of thousands or miUipns 
of modules. 

[0019] Finally, concerning the actual programming of the 
flash memories in itself, another constraint that has to; be 
taken into accoimt is intrinsic to the component, since 
programming a flash memory is equivalent to charging 
capacitors. A flash memory is composed of several small 
capacitors each provided with a very good quality insulator, 
such that they hardly discharge over time. 

[0020] However, the capacitors will discharge more or less 
quickly depending on the variation of the oxide quality in 
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manufacturing batches. Thus, if the programming of a flash 
takes X microseconds for a given circuit, it may for example 
take 1 microsecond longer for another circuit due to varia- 
tions in the oxide quality. 

[0021] These synchronization problems that arise between 
the different modules due to programming of the flash 
memory and that are intrinsic to the flash memories them- 
selves, are defects that make implementation of a specific 
programming protocol through the CAN bus unacceptable. 

[0022] Thus, one of the purposes of this invention is to 
overcome constraints related to the flash memory to solve 
the asynchronism problem due to programming the flash 
memory, thus enabling programming and parallel repro- 
gramming of onboard flash memories through the CAN bus 
at the module level. 

[0023] In a particular context in which the flash memories 
to be programmed are blank, another purpose of the inven- 
tion is to start the microprocessor directly through the CAN 
bus without using additional equipment, regardless of the 
frequency of the system and regardless of the binary 
throughput of the data transmission on the CAN bus, while 
remaining compatible with conventional start-up method- 
ologies used through the UART type serial link. Once it has 
been made possible to start-up through the CAN bus, it 
becomes possible to envisage parallel programming of flash 
memories at the module level. 

[0024] The principle of the invention described in this 
application for a CAN bus is nevertheless applicable to all 
buses of the multiple access type such as for example the 
new TTP (Time Triggered Protocol) automobile bus, the bus 
according to the American J1850 standard or the VAN bus. 

[0025] A specific communication protocol has to be 
defined for its implementation, to enable simultaneous send- 
ing of the same data to all modules for programming and 
reprogramming of onboard flash memories in parallel. 

[0026] Advantageously, the existing connections of the 
modules can be used to pass a unique configuration to each 
module, to manage asynchronism due to programming the 
flash memory. Thus, each module can be identified indi- 
vidually, and the programming station can then know how 
many modules are connected. 

[0027] As a result, several circuits or modules may be 
programmed or reprogrammed in parallel, which enables 
very large productivity gains in production lines and there- 
fore reduced costs. 

[0028] Therefore the invention relates to a process for 
programming or reprogramming the onboard reprogram- 
mable memory, characterised in that it consists of program- 
ming or reprogramming the onboard memory of several 
modules in parallel through a multiple access bus to which 
the said modules are coimected. 

[0029] Other characteristics and advantages of this inven- 
tion wiU become clearer after reading the following descrip- 
tion of a particular embodiment with reference to the use of 
a CAN bus and made with reference to the attached figures, 
given as a non-restrictive example, in which: 

[0030] FIG. 1 is' a functional diagram of a module con- 
taining the flash memory to be programmed; 



[0031] FIG. 2 shows an example of the hardware con- 
figuration of a module programming bench. 

[0032] The integrated hardware resource consisting of the 
chronometer reference 4 in FIG. 1 is used for everything 
related firstly to the trigger sequence to be implemented 
when blank flash memories have to be programmed. The 
chronometer 4 is activated by a derivative of the internal 
frequency of the system and its role will be to measure the 
transmission duration of a predefined frame comprising a 
predetermined number of binary elements. 

[0033] The exact binary throughput on the CAN can! be 
precisely calculated by measuring the transmission duration 
for a number of transitions through the internal frequency of 
the system. Thus, the microprocessor 1 can be adapted to the 

frequency of the CAN. The CAN module 7 of the circuit is 
then configured to actively participate in the communica- 
tion. 

[0034] Therefore, a first phase will consist of detecting the 
binary throughput on the CAN. 

[0035] Detection of the binary throughput is based on the 
measurement in time of a predefined frame transmitted on 
the CAN by a programming station 9. During the measure- 
ment time, the CAN module 7 in the circuit is not active. 
Detection will actually take place at the circuit input/output 
ports. Thus, the microprocessor will receive and analyse the 
frame predefined through the input/output ports (not shown 
in FIG. 1) instead of working directly with the CAN 
module. 

[0036] The microprocessor measures the transmission 
time on a reference frame comprising a large number of bits, 
preferably 29 bits, in order to obtain a good resolution. An 
attempt is made to have the largest possible number of bits, 
while making sure that the software has a small number of 
transitions to check. If there are more than 29 bits, there are 
many transitions and it then becomes more diflBcult' to 
monitor the transitions with the software at any frequency. 

[0037] The equivalent binary throughput is then calculated 
by the microprocessor 1, so that the CAN module 7 can be 
configured correctly and therefore a predefined identifica- 
tion frame valid on the CAN bus 6 acting as an acknowl- 
edgement of reception can be sent to the programming 
station 9 through the CAN module 7. 

[0038] A second phase then consists of downloading the 

loading program. 

[0039] In order to achieve this, the programming station 9 
will send a predefined number of bytes, typically 32 bytes, 
on the CAN bus 6 to the microprocessor 1 through the CAN 
module. According to one particular embodiment, a larger 
number of bytes, for example 64, is loaded in order to 
reinitialise the CAN module with the final optimum param- 
eters of the CAN. Transferring the final parameters of the 
CAN in this way with the bytes that were downloaded in the 
microprocessor makes the process more robust. 

[0040] The microprocessor will then load these bytes into 
its internal memory, which is a RAM (Random Access 
Memory) type volatile memory. Once the microprocessor 
has written a sufficient number of bytes into the RAM, it >iall 
execute the program that has just been loaded and will send 
a predefined frame signifying the end of the second phase, 
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this acknowledging reception of bytes at the programming 
station through the CAN module. 

[0041] Thus, a program embryo has been successfully 
loaded and is completely configurable. Advantageously, this 
program embryo is a loading program that can subsequendy 
be used to load a much larger number of bytes. 

[0042] Thus in a third phase, a final application may be 
downloaded from the programming station into the micro- 
processor RAM. For example, this final application may be 
software for programming the flash memory. 

[0043] Therefore to start, an initial program to load the 
internal memory of microprocessors for each module was 
downloaded through the CAN bus following prior detection 
of the binary throughput on the CAN at the module. 

[0044] Once the system has been started through the CAN 
bus, it becomes possible to start programming and to erase 
flash memories in parallel through the CAN bus. 

[0045] Thus on FIG, 2, only two modules to be pro- 
grammed (or reprogrammed), MO and Ml, are shown as an 
example. However, it is clear that the invention is intended 
for use with several modules. Modules MO and Ml com- 
municate with the programming station 9 through the CAN 
bus 6. All modules connected to the CAN bus operate at the 
same frequency and using the same software. 

[0046] Thus, initially, the user must read the predefined 
input and output statuses of the modules in order to define 
an identifier specific to the module which will subsequently 
be used to communicate with the programming station 
through the CAN. In order to achieve this, the existing 
connections of the modules, 10 and II respectively, are used 
to supply a binary identification number in the test environ- 
ment that wiU be read by the module microprocessor to 
identify itself with the programming station. 

[0047] Another approach to enable each module to have a 
unique identifier (condition necessary for parallel program- 
ming) is to power up all modules in sequence and then start 
them in sequence. The programming station can then give an 
identifier to the module when it is started. 

[0048] It then asks the module to start waiting for a 
specific end of sequence message. The station then continues 
to apply power to and to trigger subsequent modules. When 
this phase is finished, it sends the end of sequence message: 
aU modules then have a different identifier and are ready to 
accept broadcast type messages. 

[0049] Two message types are distinguished in the com- 
munication protocol according to the invention. Firstly, there 
are "broadcast" type messages, in other words information 
is broadcast to all modules connected on the CAN bus. 
These "broadcast" type messages are therefore general 
broadcast messages sent by the programming station and 
which are listened to simultaneously by all modules in 
parallel. Thus, programming, erase and verification com- 
mands are broadcast from the programming station. These 
commands are broadcast with a generic identifier that dis- 
tinguishes these "broadcast" type commands. 

[0050] There are also point to point type messages through 
identifiers specific to each module which are either messages 
from the programming station to a particular module, or 
messages firom a module to the programming station. 



[0051] Therefore, the invention includes a set of rules that 
cover the functional characteristics of the data transmission 
link, and data transmission procedwes for programming/ 
reprogramming the flash memories in parallel. 

[0052] In a first step, the programming station counts how 
many modules are connected to the bus. The programming 
station actually requests modules to identify themselves and 
to send their identification frame, through a "broadcast" type 
command. 

[0053] In a second step, the programming station then 
broadcasts programming commands to all modules in par- 
allel (or an erase command in the case of reprogrammirig). 
These programming commands are interpreted as being of 
the "broadcast" type due to the generic identifier with which 
they are associated, and comprise a write address and data 
to be programmed. 

[0054] Optionally, when programming is terminated, the 
programming station repeats the same procedure and broad- 
casts a check command, once again to be sent to all modules. 
Thus, each module uses a single '^broadcast" type message 
that includes the address and the reference data, to carry out 
a self-check using its microprocessor, by comparing the 
contents of its own flash memory with the reference that it 
received. Therefore, the checks are made in parallel, thus 
saving a large amount of time. 

[0055] According to one particular embodiment, at the end 

of the sequence, the programming station requests each 
module to send the results of programming and the check. 
Each module saves its errors while it is being programihed 
or while it is checking. 

[0056] The programming station may then count how 
many modules have been programmed, stiU using a "broad- 
cast" type command. 

[0057] However according to another embodiment, each 
module can immediately signal its errors to the program- 
ming station as soon as it has detected an error during 

programming or during the verification, using point to point 
messages provided for this purpose. 

[0058] Furthermore, depending on the type of the user's 
hardware, it may be advantageous to use an output from the 
module to control external indicators such as LEDs (Light 
Emitting Diodes), the function of which is to indicate the 
result of the programming on the programming bench. ; 

[0059] Starting from two modules to be programmed in 
parallel, a large amount of time can be saved compared with 
programming of flash memories using the UART. This time 
saving is even more significant if an erase step has to be 
implemented. For example, this is the case particularly when 
it is required to load a test program that will then be erased 
before programming the required application. 

[0060] Therefore, the protocol is intended to minimize 
software processing necessary in the module such that the 
module microprocessor spends more time programming 
than managing the communication with the programming 
station. 

[0061] In order to achieve this, a double buffer systeni is 
set up to simultaneously enable data reception and program- 
ming in memory. Thus, initially, the programming com- 
mands received from the CAN are put into a first buffer area 
acting as a waiting area. 
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[0062] Then, on reception of a transfer buffer and pro- 
gramming command from each of the modules, program- 
ming of the flash memory begins in each module using the 
data stored in the first data buffer area that up to then had 
been in reception, and simultaneously a second buffer area 
is assigned to reception of commands from the CAN. 
Therefore, there is a first process to fill a data buffer and 
another process to process these data. The changeover from 
one process to another means that modules can be pro- 
grammed very efl&ciently with minimum communication, 
and therefore an optimum time saving. 

[0063] Large buffers have lo be used to further minimize 
software processing necessary in the module for processing 
of communications between the module and the program- 
ming station. The changeover from one buffer to another is 
made by a transfer command sent from the programming 
station to the module. Similarly, each module will send a 
report message to the programming station when it has 
finished programming the buff"er. 

[0064] We will now see details of all commands included 
in the protocol according to the invention. 

[0065] The protocol enables programming of the flash 
memory in parallel through the CAN bus, and therefore the 
first step is to use a number of "broadcast" type commands, 
in other words commands broadcast from the programming 
station to all modules connected on the CAN bus, and any 
of the modules can receive them. 

[0066] A first send_ID command consists of asking naod- 
ules to send their identifier. Therefore each module must 
send its identifier specific to it, which will enable the 
programming station to count the number of modules that 
are connected to it through the CAN bus and to monitor ^ 
them individually. 

[0067] Another "broadcast" type command is the start 
filling buffer command. This command is made by sending 
a start memory address, count and data to be written into the 
memory at the said address, on the CAN to all modules. For 
example, the count is used to inform the module about how 
many binary words it will receive after receiving the filling 
buffer command. 

[0068] Subsequently, continue filling buffer commands are 
broadcast consisting only of data, and the memory address 
automatically increments itself. Thus, it is possible to mini- 
mize the number of auxiliary bits to be transmitted and 
therefore the data transmission time. 

[0069] Therefore each module receives data until it 
receives a new start filling buffer command, or until it 
receives a transfer buffer command or a programming 
command at the initiative of the programming station. 

[0070] The transfer buffer and programming command 
consists of requesting each module to start programming 
starting from the buffer that was in data reception and to 
allocate the other buffer to reception. Thus, the buffer that 
was in reception becomes the buffer that will be used as 
reference for programming, and the buffer that was in 
programming becomes the reception buffer. 

[0071] The command that follows the transfer buffer and 
programming command described above is the transfer 
buffer and verification command which is also a "broadcast" 
type command. On reception of this command, each module 



starts the verification starting from the buffer that was in 
reception, and the other buffer is then allocated to reception. 
Therefore, the verification takes place starting from a single 
command broadcast to all modules at the same time and each 
module checks the result of its programming by itseff. 
Therefore, this is a "broadcast" type of verification, inducing 
a large time saving for the entire process, 

[0072] The start filling buffer and the continue filling 
buffer commands are actually independent, as are the pro- 
gramming and verification commands. It is only when 
buffers are transferred that a notification is made about 

whether the transfer command is to program or to verify. 

[0073] The protocol includes another command broadcast 
by the programming station to all modules, that consists of 
asking for information to be sent about the status of each 
module. Each module then sends its programming status, for 
example after verification. 

[0074] Finally, a last broadcast command is necessary, 
which is the erase command. The erase command is broad- 
cast by the programming station on the CAN bus to which 
all modules are connected, and controls starting to erase 
memory in all modules at the same time. This command is 
used particularly for parallel reprogramming of flash memo- 
ries through the CAN bus. 

[0075] Depending on the implementation chosen for the 
protocol, the erase command is preferably used in two steps 
for better security. Thus, a first Prepare erase command 
consists of transferring data banks to be erased into the flash 
memory as parameters, followed by a second command to 
confirm the erase consisting of executing the previous 
command. Obviously, the confirm erase command can be 
optional. 

[0076] The protocol according to the invention also useis a 
certain number of specific messages from modules to the 
programming station. Therefore, these are no longer "broad- 
cast" type messages as above, but point to point type 

messages. 

[0077] Specific identifiers are necessary for each of the 
above mentioned types of messages, so that communication 
is possible between each of the modules and the program- 
ming station. 

[0078] A global identifier on the CAN is a an identifier of 
the type with at least 11 bits. Some of these bits define the 
command type and others define the module number. In this 
case, the specific identifiers to be used on the CAN bus are 
derived from a logical combination between generic iden- 
tifiers allocated for each command and the identifier specific 
to the module, so that a unique identifier is sent on the CAN 
for each message from a module to the programming station. 

[0079] One important command to be included among the 
specific point to point commands from modules to the 
programming station is the command_OK command. The 
command OK command is sent by each module to the 
programming station after a successful programming/veri- 
fication of its data buffer (or after a successful erase). 

[0080] Advantageously, since some asynchronism has to 
be managed due to programming of its flash memories, the 
programming station starts a timeout so as to leave sufficient 
time for each module to correctly program (or verify) its 
memory. After a given time predefined by the programming 
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Station, the programming station returns an individual com- 
mand using the unique identification for each module, to all 
modules that did not reply, to notify them that they are in an 
error status. 

[0081] However, available point to point commands from 
modules to the programming station may also include a 
programming error command. Thus, when a module detects 
an error during programming (for example when it cannot 
write a value), this programming error command enables it 
to signal this error to the programming station immediately, 
without waiting for the end of the timeout. 

[0082] Similarly, a verification error command is provided 
that gives each module an opportunity to report a verifica- 
tion error to the programming station immediately that it 
detects it, rather than at the end of the verification process. 

[0083] The programming station starts the timeout and 
waits until all modules have returned either the comman- 
d_OK command or an error message. 

[0084] These programming error and verification error 
commands sent as soon as an error is detected actually 
optimise programming times. As a result of these different 
commands, the programming station does not need to wait 
for the end of the timeout to deal with any errors. Once 
again, this is made possible by the unique identifier allocated 
to each module connected onto the CAN bus. 

[0085] In the case of an erase for subsequent reprogram- 
ming of the flash memory, an erase error command can also 
be used based on the same principle and with the same 
purpose as the programming error and verification error 
commands used during parallel programming of the differ- 
ent modules, 

[0086] One last specific point to point command from the 
modules to the programming station is the module status 
command. This command is sent by each module in 
response to a request (of the "broadcast" type) firom the 
programming station for this purpose. 

[0087] The protocol according to the invention also 
includes specific commands firom the programming station 
to modules. Therefore, it is another point to point command. 

[0088] In the same way as for specific commands from 
modules to the programming station, specific identifiers 
have to be generated on the CAN so that each module can 
know if the message concerns it. To achieve this, the generic 
identifiers that are used for the different required commands 
will be particularized by adding the specific index for the 
module to which the command is addressed at the end of 
each generic identifier, thus enabhng the point to point 
communication and consequently transmission of specific 
messages from the programming station to the modules. 

[0089] These specific messages from the programming 
station to the modules include the send status command that 
consists of requesting a module to send its status. 

[0090] A stop command consists of requesting a module to 
stop all operations immediately. This command can prevent 
modules that contain flash memory programming errors 
from disturbing the programming of the other modules. 

[0091] A stop timeout command in the form of a specific 
module to programming station message, for example of the 
command_OK command type described above, notifies 



modules from which the response is expected that the 
timeout set in the programming station has terminated. 
When it receives this stop timeout command, the module in 
question must consider itself in error. 

[0092] An opera tion_OK command must be given at the 
end of the programming or verification (or at the end of the 
erase when a parallel reprogramming process is used). This 
point to point operation_OK command is necessary because 
the programming station provides the guarantee that every- 
thing took place correctly in a specific module. The pro- 
gramming station provides the final confirmation to each 
module that it is correctly programmed, even if the pro- 
gramming station uses a "broadcast" type command 
described above in the description to delegate the verifica- 
tion of the programming to each module, with each module 
subsequently transferring the result of its verification to the 
programming station. 

[0093] The module may advantageously use reception of 
this operation_OK command to command a light emitting 
diode on one of the existing output ports on the module. 

[0094] Thus, from a protocol point of view, the program- 
ming station checks that it has actually received all acknowl- 
edgements of reception from each module and then uses the 
operation_OK command to notify that everything took place 
correctly throughout the process to each specific module. 

[0095] After describing all specific "broadcast" type com- 
mands included in the protocol according to the invention, 
we will now consider an example of a programming and 
verification stream using these different commands. All 
commands transit on the CAN bus independently of where 
they are sent from. 

[0096] Therefore, a first step uses the send_ID command 
sent by the programming station, and each module replies to 
it by sending its specific identifier. 

[0097] A second step consists of sending the start filling 
buffer command, which marks the beginning of reception; on 
a buffer. In a third step, the continue filling buffer command 
is sent on the CAN, with the result of continuing to fill the 
buffer with the addresses being incremented. 

[0098] A fourth step uses either continue filUng buffer 
commands or a new start filling buffer command in the case 
in which there is a discontinuity in the data addresses to be 
programmed. 

[0099] The transfer buffer and programming command is 
sent in a fifth step. Programming then begins in each module 
starting from the buffer that was in reception, and the second 
buffer is simultaneously allocated in reception. The transfer 
buffer and verification command can also be used during this 
step, a verification is then started and this verification takes 
place in each module in parallel, as already explained. : 

[0100] A sixth step consists of repeating the filling buffer 
commands. Thus, steps 2 to 5 are repeated until the end of 
the programming process. 

[0101] In a seventh step, each module in parallel then 
sends either the command_OK command which indicates 
that the data in the last buffer were successfully processed, 
or the programming error command that indicates an error 
diiring programming, or the verification error command that 
indicates an error during the verification. 
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[0102] The eighth step consists of sending the stop timeout 
command, from the programming station. This command 
terminates the timeout used in the programming station that 
comes in the tinie period during which the modules have to 
carry out their programming. Modules that receive this stop 
timeout command must consider themselves in error. 

[0103] Finally, the last step in the programming and veri- 
fication process consists of sending the operation_OK com- 
mand, llie programming station can then use this command 
to confirm individually to each module that everything took 
place correctly throughout the entire process. 

[0104] The command stream on the CAN is simpler if 
flash memories of modules are erased in order to do parallel 
reprogramming. 

[0105] A first step consists of using the send_ID com- 
mand, each module replies by sending its specific identifier, 
and the programming station can then count the number of 
modules to be erased. 

[0106] The erase preferably takes place in two steps using 
two "broadcast" type commands: firstly a prepare erase 
command and secondly a confirm erase command. 

[0107] The modules then send either a command_OK type 
command indicating that they correctly executed the erase 
command, or an erase error command. 

[0108] The operation_OK command is sent if all modules 
completed the erase successfully. With this command, the 
programming station specificaDy confirms that the erase was 
successful to each module. Therefore this command is sent 
in response to the command^OK command output from the 
modules. 

[0109] Finally, the stop timeout command is used in the 
last step. Therefore, modules that did not reply during this 
timeout and which receive this command must go into the 
enor status. 

[0110] Therefore, the protocol according to the invention 
defines rules for writing software that will enable parallel 
programming of a blank or non-blank on board flash 
memory of several modules through the bus to which the 
modules are connected. This protocol can be defined by the 
use of existing module input/output ports to transfer a 
unique configuration to each module. A logical combination 
can then be made between identifiers allocated to the CAN 
bus for command types and identifiers specific to each 
module to make communication according to the protocol 
possible. 

[0111] In the case of blank flash memories, the invention 
also defines a process to download program code through 
the bus and to execute it, ehminating all external constraints 
(frequencies, binary throughput). 

[0112] The example embodiment that has just been 
described is given with particular reference to the use of a 
CAN bus. However, the invention is not restricted to the use 
of a CAN bus and any other multiple access bus not 
dedicated to this purpose may be used in paraUel program- 
ming of flash memories onboard a module. To achieve this, 
all that is necessary is that the bus concerned is accessible in 
parallel, either inherently or because the protocol has been 
modified in a manner known in itself so that it becomes 



accessible in parallel (bus access conditions, redefinition of 
message headers to enable "broadcast" type messages . . ). 

[0113] As already mentioned, the process according to the 
invention as described with reference to the example iise of 
the CAN bus is actually applicable to any type of multiple 
access bus such as the new TPP automobile bxis, the bus 
according to the American J1850 standard, the VAN bus, etc. 

1. Process for programming or reprogramming ' an 
onboard reprogrammable memory (5), characterised in that 
it consists of programming or reprogramming the onboard 
memory of several modules (MO, Ml, . . . ) in parallel, using 
a multiple access biis (6) to \^ch the said modules are 
connected. 

2. Process according to claim 1, characterised in that it 
consists of supplying a binary identifier that is specific to 
each module ^0, Ml . . . ) in a test environment using the 
existing connections (10, II . . . ) for each module, so that 
each of the said modules can identify itself with a program- 
ming station (9), through the bus. 

3. Process according to claim 1 or 2, characterised in that 
it consists of defining a communication protocol on the bus 
(6) using "broadcast" type commands broadcast to all mod- 
ules, and point to point type commands, the said point-to- 
point type commands comprising specific commands from 
modules (MO, Ml . . . ) to the programming station (9), and 
specific commands from the programming station to the 
modules. 

4. Process according to claim 3, characterised in that the 
"broadcast" type commands are broadcast with a generic 
identifier that distinguishes them. 

5. Process according to claim 3 or 4, characterised in that 
it consists of generating specific identifiers on the bus for 
transmitting point-to-point type commands. 

6. Process according to claim 5, characterised in that the 
specific identifiers on the bus are derived from a logical 
combination between generic identifiers allocated for each 
command and the identifier specific to the module. ; 

7. Process according to one of claims 3 to 6, characterised 
in that when the onboard memory of the modules to . be 
programmed is not blank, the memory of all modules is 
erased at the same time using a broadcast type command. 

8. Process according to claim 7, characterised in that the 
erase memory command in parallel is used in two steps 
consisting of: 

transferring data banks to be erased in the onboard 
memory of each module, as parameters, 

confirm the erase by executing the previous command. 

9. Process according to one of claims 3 to 8, characterised 
in that it consists of using a double buffer system in the 
protocol to enable simultaneous data reception and program- 
ming in the memory of the modules. 

10. Process according to one of claims 3 to 9, character- 
ised in that a check of the programming is made in each 
module in parallel using a "broadcast" type command. ; 

11. Process according to claim 10, characterised in that 
the verification command comprises an address and a ref- 
erence data, each of the modules self checking itself through 
its microprocessor (1) by comparing the contents of its own 
memory with the received reference. 

12. Process according to claim 1 or 2, characterised in that 
a step prior to programming is performed in a context in 
which the onboard memories (5) to be programmed are 
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blank, consisting of starling the microprocessor (1) on each 
module (MO, Ml - - . ) directly through the bus (6), 
regardless of the frequency of the system and regardless of 
the binary throughput on the bus. 

13. Process according to claim 12, characterised in that 
the start sequence comprises the following phases consisting 
of: 

a — detecting the binary throughput on the bus, 

b — downloading a loading program into the internal 
memory of the microprocessor (1), 

c — downloading a final application into the internal 
memory of the microprocessor (1). 

14. Process according to claim 13, characterised in that 
phase a comprises the following steps consisting of: 

making a time measurement of a predefined firame trans- 
mitted on the bus comprising a sufficient number of 
binaries to obtain good precision, 

calculating the equivalent binary throughput. 



15. Process according to claim 13, characterised in that 
phase b consists of sending a sufficiently large predefined 
number of bytes on the bus to the microprocessor (1) to 
transfer the final optimum parameters for the bus (6) at the 
same time. 

16. Process according to one of the previous claims, 
characterised in that it is more particularly applicable, to 
onboard flash memory type memories. 

17. Process according to one of the previous claims, 
characterised in that it is used through a CAN bus. 

18. Process according to any one of claims 1 to 16, 
characterised in that it is xised through a TPP bus. 

19. Process according to one of claims 1 to 16, charac- 
terised in that it is used through a bus according to the 
American J1850 standard. 

20. Process according to one of claims 1 to 16, charac- 
terised in that it is used through a VAN bus. 

* « * « « 
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